Many communication systems transfer a media stream, such as a video, audio, etc., over wired and/or wireless links. For various reasons, such as load, transmission conditions and the like, a capacity of the links varies over times. The capacity is often indicated in terms of available bandwidth. Consider a link that has an available bandwidth of X kilobits per second (kbps). Then, a media stream, coded with a bit rate of X kbps or less, can be successfully transferred on the link. In this example, the available bandwidth is considered to denote bandwidth that is actually available for a media stream, in other cases overhead may need to be considered. The media stream is usually divided into frames, which are then encoded in a media sender, transmitted over the link and decoded in a media receiver. When transmitting real-time media over Internet Protocol (IP) networks the encoded frames are typically encapsulated into Real-time Transport Protocol (RTP) packets, which are then further packetized into User Datagram Protocol (UDP) packets and then into IP packets. The media stream is typically said to be successfully transferred when requirements concerning delay, frame loss and throughput are met. The link may connect a media sender, such as a Personal Computer (PC), tablet, mobile phone, to a media receiver, such as another tablet Personal Computer (PC), or the like. However, should the available bandwidth decrease, either temporarily or permanently, it would no longer be possible to successfully transfer the media stream. In order to compensate for the variation of available bandwidth, a concept of rate adaptation has been proposed. With rate adaptation, the bit rate of the media stream is thus adapted to the currently available bandwidth. The rate adaptation can be receiver-based or sender-based as will be explained in the following.
Receiver-Based Rate Adaptation
Receiver-based rate adaptation means that a decision on how to adapt the bit rate is taken by the media receiver. Generally, the receiver-based adaptation comprises the following steps:
1 The media receiver evaluates performance of a received media stream. For example packet loss, delay, jitter and/or estimated throughput are evaluated.
2 The media receiver determines the bitrate that should be suitable for the current operating conditions, e.g. the currently available bandwidth.
3 An adaptation request is signalled back to the media sender requesting a higher or lower bitrate as appropriate in view of the currently available bandwidth.
4 The media sender usually adapts to the received bitrate, but the media sender may choose to adapt in a slightly different way, if it has reasons to do so. For example, the media sender may use a lower bitrate than what was requested or the media sender may delay switching to a higher bitrate. In general, though, the media sender applies the requested bitrate.
A known receiver-based rate adaptation procedure is described in Technical Specification (TS) 26.114 of Third Generation Partnership Project (3GPP). The receiver-based rate adaptation is defined for Multimedia Telephony Service (MTS) for Internet Protocol Multimedia Subsystem (IMS), often abbreviated MTSI. The receiver evaluates the performance, as in step 1 above. Then, the receiver sends a rate request, such as a Temporary Maximum Media stream Bit rate Request (TMMBR), back to the sender using Real-time Transport Control Protocol (RTCP). RTCP transmission rules, see below, impact when the adaptation requests can be sent.
Sender-Based Rate Adaptation
Sender-based rate adaptation means that the decision on how to adapt the bit rate is taken by the media sender. Generally, the sender-based adaptation comprises the following steps:
1 The media receiver collects metrics about performance of the received media stream. The metrics may concern for example: packet losses, delay or jitter.
2 The media receiver sends the metrics back to the media sender, typically using RTCP. The metrics are typically encapsulated in so called RTCP Receiver Reports.
3 The media sender determines the bitrate that should be suitable for the current operating conditions, such as the currently available bandwidth. The media sender may take other information into account when determining the bitrate, for example if it is sending multiple streams and if it then is better to divide the available bitrate in a different way than what is suggested by the performance metrics.
4 The media sender adapts the bit rate of the media stream to the determined bit rate.
A known sender-based rate adaptation procedure is described in Internet-Draft Self-clocked Rate Adaptation for Multimedia (SCReAM) of Jul. 6, 2015, to I. Johansson and Z. Sarker as within the Internet Engineering Task Force (IETF) RTP Media Congestion Avoidance Techniques (RMCAT) working group, where RTP is short for Real-time Transport Protocol.
The feedback signalling, i.e. the metrics above, in SCReAM includes the following information:                Highest received RTP sequence number: The highest received RTP sequence number for a given Synchronization Source (SSRC), such as the media stream.        n_lost: Accumulated number of lost RTP packets for the SSRC        Timestamp: A timestamp value indicating when the last packet was received which makes it possible to compute the one-way (extra) delay (OWD).        n_ECN: Accumulated number of Explicit Congestion Notification-Congestion Experienced (ECN-CE) marked RTP packets for the given SSRC        Source quench bit (Q): Makes it possible to request the sender to reduce its congestion window. This is useful if so called Real-time Communication on the Web (WebRTC) media is received from multiple hosts and it becomes necessary to balance the bit rates between the streams from the multiple hosts.        
With SCReAM, relatively frequent feedback messages, say 20˜30 RTCP packets per second, should be sent. Therefore, SCReAM uses Reduced-Size RTCP in order to provide the relatively frequent feedback, while still consuming a relatively low bandwidth of RTCP.
RTCP Transmission Rules
The RTCP transmission rules limit not only how frequently RTCP packets can be sent but also when each individual RTCP packet can be transmitted.
The RTCP transmission rules for the Audio Video Profile (AVP) profile are defined in Request For Comments 3550 (RFC3550), “RTP: A Transport Protocol for Real-Time Applications” from IETF. A simplified description is that, after sending an RTCP packet, the RTCP protocol function determines the interval it has to wait until it will send the next RTCP packet. This interval depends on: the allocated RTCP bandwidth; the number of end-points in the session; and the portion of active and non-active end-points. Since the RTCP packets can have varying size, the RTCP protocol function also monitors how much of the RTCP bandwidth that has been used recently. The RTCP protocol function then adds a +/−50% uniform randomization to the calculated transmission interval. The transmission interval will therefore not be constant but will vary over time.
When TMMBR is sent with Extended Audio Video Profile, also known as AVPF, feedback messages, which uses the modified RTCP transmission rules defined in IETF RFC4585, “Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)”. The Audio Video Profile with Feedback (AVPF) profile has three modes:
1. Regular RTCP mode, which is used when there is no need to send any urgent feedback messages. In this mode, the normal RTCP transmission rules defined in the above mentioned RFC3550 are used.
2. Immediate Feedback mode.
3. Early RTCP mode.
The Immediate Feedback mode and the Early RTCP mode are described in detail in RFC4585. However, both these modes allow for sending RTCP packet(s) without waiting the normal RTCP transmission interval according to RFC3550. This is used for sending an urgent feedback message with no or short delay, for example to send an adaptation request, e.g. TMMBR. This shortens the adaptation loop and gives faster adaptation to varying operating conditions.
In some scenarios, the sender and the receiver supports different rate adaptation procedures. Then, in order to provide interworking between the sender and the receiver, a media gateway, located somewhere between the sender and the receiver, may need to transcode the media stream to obtain matching rate adaptation procedures for the sender and the receiver. Such transcoding is costly, e.g. in terms of processing time, delay and processing resources. Therefore, so called Transcoding Free Operation (TrFO) of the media gateway is preferred.
In 3GPP, it has been discussed how to achieve TrFO for interworking between WebRTC and MTSI. The discussions have aimed at solving control plane issues.
In an exemplifying scenario, a media sender is a MTSI client, which uses TMMBR as rate adaptation, and a media receiver is a RMCAT client, which uses SCReAM as rate adaptation. Thus, different rate adaptation procedures are used in the media sender and the media receiver. Then, in order to avoid transcoding the media sender and the media receiver need to fall back to another rate adaptation procedure that both support. For example, the media sender and the media receiver can use RTCP Sender Reports (SR) and a RTCP Receiver Reports (RR) to obtain interworking in a user plane between the media sender and the media receiver. A problem with this solution is though that RTCP SR/RR is quite coarse, which would not yield a sufficiently good rate adaptation.